\documentclass[a4paper,titlepage,11pt]{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\setlength{\parskip}{\medskipamount}
\setlength{\parindent}{0pt}
\usepackage{graphicx}
\usepackage{a4wide}
\usepackage[portuges,brazilian]{babel} % need to be invoked BEFORE xypic
\shorthandon" % needed so that the meaning of " is the same when xypic is loaded and when it's invoked.
\usepackage{amssymb, amsmath}
\usepackage{rotating}
\usepackage[all]{xy}
\usepackage{cancel}
\usepackage{fancyhdr}
\usepackage{enumerate}
\usepackage{units}
%\usepackage[notref,color,final]{showkeys}
\usepackage[aboveskip=3pt,font={small,sf},labelfont=bf]{caption}
\usepackage{subfig}
\usepackage[strict]{changepage}
\usepackage{fancyvrb}
\usepackage{xcolor}
\usepackage{multirow}

%%%
%%% TITLE PAGE
%%%

\newcommand{\mydivision}{Divisão de Ciência da Computação\\Departamento de Engenharia de Software}

\newcommand{\mydiscipline}{CES-35: Redes de Computadores e Internet}

\newcommand{\mysupertitle}{Laboratório 3}

\newcommand{\mytitle}{Construindo um Sistema de Bate-Papo}

\newcommand{\myname}{Cesar R. Kawakami\\Leonardo R. C. Carvalho\\Guilherme R. N. de Souza}

\newcommand{\myfieldAname}{Alunos}

\newcommand{\myfieldAcontent}{\myname}

\newcommand{\myfieldBname}{Professora}

\newcommand{\myfieldBcontent}{Cecília de A. C. Cesar}

\newcommand{\myfieldCname}{\ }

\newcommand{\myfieldCcontent}{\ }

\newcommand{\mydate}{8 de Novembro de 2010}

\renewcommand{\maketitle}{%
 	\begin{titlepage}
		\begin{center}
			\includegraphics[scale=0.125]{/Users/firer/Library/TeXShop/Templates/ITA/ita}\\
			\ \\ % forca uma linha em branco
			\textsc{%
				\Large Instituto Tecnológico de Aeronáutica\\
				\large%
				\ \\
				\mydivision\\
				\textbf{\mydiscipline}\\
			}
			\vspace{2cm}
			\textbf{%
				\textsc{\large \mysupertitle}\\
				\ \\
				\huge \mytitle\\
				\ \\
				\Large Relatório Final
			}
			\vspace{2cm}
			\begin{flushleft}
				\large \myfieldAname\\
				\Large \myfieldAcontent\\
				\ \\
				\large \myfieldBname\\
				\Large \myfieldBcontent\\
				\ \\
				\large \myfieldCname\\
				\Large \myfieldCcontent\\
			\end{flushleft}
			\vfill
			{\large \mydate}
		\end{center}		
	\end{titlepage}
}	

%%%
%%% PAGE SETTINGS
%%%

% FANCY HEADERS
\pagestyle{fancy}
\fancyhead{}
\fancyfoot{}
\fancyhead[LO]{\small\textsf{Laboratório 3: \mytitle}}
%\fancyhead[RO]{\small\textsf{Kawakami, Carvalho, Souza}}
\fancyfoot[CO]{\textsf\thepage}
\setlength{\headheight}{14pt}
%\setlength{\footheight}{14pt}
\renewcommand{\headrulewidth}{0.4pt} 
%\renewcommand{\footrulewidth}{0.4pt}

%%%
%%% MANY FLOATS
%%%
\renewcommand{\topfraction}{.85}
\renewcommand{\bottomfraction}{.7}
\renewcommand{\textfraction}{.15}
\renewcommand{\floatpagefraction}{.66}
\renewcommand{\dbltopfraction}{.66}
\renewcommand{\dblfloatpagefraction}{.66}
\setcounter{topnumber}{9}
\setcounter{bottomnumber}{9}
\setcounter{totalnumber}{20}
\setcounter{dbltopnumber}{9}

%%%
%%% SPECIFIC COMMANDS
%%%
\fvset{frame=lines,fontsize=\small,xleftmargin=7pt,xrightmargin=7pt,framerule=1pt,resetmargins=true}

\newcommand{\Lap}[1]{\mathcal{L}\left\{#1\right\}}
\newcommand{\Equiv}{\Longleftrightarrow}
\newcommand{\Impl}{\Longrightarrow}
\newcommand{\DATAHERE}{\colorbox{yellow}{DADOS}}

%%%
%%% BEGIN DOCUMENT
%%%

\begin{document}

\maketitle

\section{Objetivos}

O objetivo do experimento é o seguinte.

\begin{itemize}
	\item Aprender princípios de programação em rede por meio do desenvolvimento de uma aplicação de bate-papo.
\end{itemize}

\section{Protocolo}

\subsection{Cenários e Casos de Uso}

\begin{itemize}
	\item Cliente pergunta quais salas existem junto ao coordenador
	\begin{enumerate}
		\item[1.] Coordenador responde com uma lista de (nome da sala, porta do servidor) 
	\end{enumerate}
	
	\item Cliente pergunta quais salas existem junto ao coordenador
	\begin{enumerate}
		\item[1.]  Coordenador responde com uma lista de (nome da sala, porta do servidor)
	\end{enumerate}	
	
	\item Cliente cria uma sala junto ao coordenador
	\begin{enumerate}
		\item[1.]  Coordenador escolhe aleatoriamente uma porta e dispara um novo servidor
		\item[2.] Coordenador responde com (nome da sala, porta do servidor)
	\end{enumerate}	
	
	\item Cliente elimina uma sala sem associados junto ao coordenador
	\begin{enumerate}
		\item[1.]  Coordenador envia pedido de eliminação ao servidor correspondente
		\item[2.] Servidor responde afirmativamente se não tiver associados
		\item[3.] Coordenador responde se sala foi eliminada ou sala ainda tem associados
	\end{enumerate}	
	
	\item Cliente se associa a um servidor junto ao servidor
	\begin{enumerate}
		\item[1.]  Cliente envia nome de usuário
		\item[2.] Servidor responde OK
	\end{enumerate}	
	
	\item Cliente envia uma mensagem junto ao servidor
	\begin{enumerate}
		\item[1.]  Cliente envia mensagem
		\item[2.] Servidor envia (nome de usuário, mensagem) a outros associados
		\item[3.] Servidor responde OK
	\end{enumerate}	
	
	\item Cliente desassocia-se do servidor junto ao servidor
	\begin{enumerate}
		\item[1.]  Servidor responde OK
	\end{enumerate}
\end{itemize}

\subsubsection{Notas}

Cliente deve receber os parâmetros de endereço e porta do coordenador via argc/argv. Coordenador e servidor devem receber o parâmetro de porta via argc/argv e escutam em todos os IPs disponíveis.

\subsection{Limites}

Limites estabelecidos no protocolo.

\begin{center}
	\begin{tabular}{cc}
		\hline
		Parâmetro & Limite  \\
		\hline
		Tamanho do nome de uma sala & 64 bytes \\
		Tamanho do nome de um usuário & 64 bytes \\
		Tamanho de uma mensagem & 65533 bytes ($2^{16} - 2$)\\
		Número total de salas & 128 \\
		Tamanho de uma mensagem de erro & 256 bytes \\
		\hline
	\end{tabular}
\end{center}

\subsection{Diagramas de estados}

\subsubsection{Cliente}

\begin{center}
	\includegraphics[width=\textwidth]{estados_cliente}
\end{center}

\subsubsection{Coordenador}

\begin{center}
	\includegraphics[width=\textwidth]{estados_coord}
\end{center}

\subsubsection{Servidor}

\begin{center}
	\includegraphics[width=\textwidth]{estados_servidor}
\end{center}

\subsection{Especificação das mensagens}

\subsubsection{Encapsulamento}

Todas as mensagens serão encapsuladas segundo a seguinte figura.

\begin{center}
	\includegraphics{encap}
\end{center}

\subsubsection{Cliente para coordenador}
\begin{list}{}{\setlength\leftmargin{-3cm}\setlength\rightmargin{-3cm}}\item
\small\centering
	\begin{tabular}{ccccp{6cm}}
		\hline\hline
		Mensagem & Tipo & Dado associado & Tamanho & Conteúdo  \\
		\hline\hline
		\multirow{1}{*}{LC\_ROOM\_LIST} & 0 & - & - & - \\
		\hline
		\multirow{1}{*}{LC\_CREATE\_ROOM} & 1 & ROOM\_NAME & 1..65 bytes & Nome da sala (null-terminated string) \\
		\hline
		\multirow{1}{*}{LC\_DELETE\_ROOM} & 2 & ROOM\_PORT & 2 bytes & Porta da sala a ser eliminada (network byte order) \\
		\hline\hline
	\end{tabular}
\end{list}

\subsubsection{Coordenador para cliente}
\begin{list}{}{\setlength\leftmargin{-3cm}\setlength\rightmargin{-3cm}}\item
\small\centering
	\begin{tabular}{ccccp{6cm}}
		\hline\hline
		Mensagem & Tipo & Dado associado & Tamanho & Conteúdo  \\
		\hline\hline
		\multirow{4}{*}{CL\_ROOM\_LIST} & \multirow{4}{*}{0} & ROOM\_COUNT & 1 byte & Número de salas abertas \\
		  &  & ROOM\_NAME & 1..65 bytes & Nome da sala (null-terminated string), ROOM\_COUNT vezes\\
		  &  & ROOM\_PORT & 2 bytes & Porta da sala, ROOM\_COUNT vezes \\
		\hline
		\multirow{1}{*}{CL\_ROOM\_CREATED} & 1 & - & - & - \\
		\hline
		\multirow{1}{*}{CL\_ROOM\_DELETED} & 2 & - & - & - \\
		\hline
		\multirow{1}{*}{CL\_ROOM\_HAS\_ASSOCIATES} & 3 & - & - & - \\
		\hline\hline
	\end{tabular}
\end{list}

Na mensagem CL\_ROOM\_LIST, cada par (ROOM\_NAME, ROOM\_PORT) é repetido ROOM\_COUNT vezes.
	
\subsubsection{Cliente para servidor}
\begin{list}{}{\setlength\leftmargin{-3cm}\setlength\rightmargin{-3cm}}\item
\small\centering
	\begin{tabular}{ccccp{6cm}}
		\hline\hline
		Mensagem & Tipo & Dado associado & Tamanho & Conteúdo  \\
		\hline\hline
		\multirow{1}{*}{LS\_ASSOCIATE} & 0 & USER\_NAME & 1..65 bytes & Nome do usuário (null-terminated string)\\
		\hline
		\multirow{1}{*}{LS\_DEASSOCIATE} & 1 & - & - & - \\
		\hline
		\multirow{1}{*}{LS\_MESSAGE} & 2 & MESSAGE & 1..65534 bytes & Mensagem (null-terminated string) \\		
		\hline\hline
	\end{tabular}
\end{list}



\subsubsection{Servidor para Cliente}
\begin{list}{}{\setlength\leftmargin{-3cm}\setlength\rightmargin{-3cm}}\item
\small\centering
	\begin{tabular}{ccccp{6cm}}
		\hline\hline
		Mensagem & Tipo & Dado associado & Tamanho & Conteúdo  \\
		\hline\hline
		\multirow{1}{*}{SL\_ASSOCIATE\_OK} & 0 & - &  -  & -\\
		\hline
		\multirow{1}{*}{SL\_DEASSOCIATE\_OK} & 1 & - & -  & -\\
		\hline
		\multirow{1}{*}{SL\_MESSAGE} & 2 & MESSAGE & 1..65534 bytes & Mensagem (null-terminated string) \\
		\hline\hline
	\end{tabular}
\end{list}



\subsubsection{Servidor para Coordenador}
\begin{list}{}{\setlength\leftmargin{-3cm}\setlength\rightmargin{-3cm}}\item
\small\centering
	\begin{tabular}{ccccp{6cm}}
		\hline\hline
		Mensagem & Tipo & Dado associado & Tamanho & Conteúdo  \\
		\hline\hline
		\multirow{1}{*}{SC\_PONG} & 0 & - &  -  & -\\
		\hline
		\multirow{1}{*}{SC\_ROOM\_HAS\_ASSOCIATES} & 1 & - & -  & -\\
		\hline
		\multirow{1}{*}{SC\_ROOM\_DELETED} & 2 & - & -  & -\\
		\hline\hline
	\end{tabular}
\end{list}



\subsubsection{Coordenador para Servidor}
\begin{list}{}{\setlength\leftmargin{-3cm}\setlength\rightmargin{-3cm}}\item
\small\centering
	\begin{tabular}{ccccp{6cm}}
		\hline\hline
		Mensagem & Tipo & Dado associado & Tamanho & Conteúdo  \\
		\hline\hline
		\multirow{1}{*}{CS\_PING} & 0 & - &  -  & -\\
		\hline
		\multirow{1}{*}{CS\_DELETE\_ROOM} & 1 & - & -  & -\\
		\hline\hline
	\end{tabular}
\end{list}

\subsection{Comentários}

São desconsideradas situações de erro raras, como erro durante a criação do processo servidor. Ademais, como o protocolo TCP informa sobre a correta recepção dos dados pela contraparte, temos que falhas durante a tentativa de transmissão podem ser interpretadas como falha da rede ou queda inesperada da contraparte e relatar erro ao usuário. No caso de erro no servidor ao enviar uma mensagem a um determinado cliente, consideramo-no, então, desconectado.

As mensagens curtas e esperádicas, como a comunicação entre o coordenador e o servidor, fazem a requisição de comunicação todas as vezes em que serão utilizadas, ou seja, o file descriptor é fechado ao final de cada comunicação.

As responsabilidades no trabalho foram distribuídas da seguinte forma:
\begin{list}{}{\setlength\leftmargin{-3cm}\setlength\rightmargin{-3cm}}\item
\small\centering
	\begin{tabular}{ccccp{6cm}}
		\hline\hline
		Aluno & Sistema \\
		\hline
		\multirow{1}{*} {Cesar Ryudi Kawakami} & {Cliente} \\
		\hline
		\multirow{1}{*} {Guilherme R. N. de Souza} & {Servidor} \\
		\hline
		\multirow{1}{*} {Leonardo R. de C. Carvalho} & {Coordenador} \\
		\hline\hline
	\end{tabular}
\end{list}

\section{Visão geral do código}
Todo o código está devidamente comentado facilitando sua leitura. Essa seção tem a função de dar uma visão geral do funcionamento do software, para maior detalhamento olhar a documentação. Além disso, o programa possibilita a execução em forma de debug, que detalha o que está ocorrendo fornecendo informações cada vez que uma ação importante será executada. Para ativar o modo de debug basta definir a variável DEBUG na compilação dos arquivos.

\subsection{Cliente}

No código do cliente, as estruturas \verb|MessageLC|, \verb|MessageLS|, \verb|MessageSL| e \verb|MessageCL| (presentes no arquivo \verb|messages.h|) e seus derivados têm por utilidade guardar as informações referentes às mensagens especificadas no protocolo da aplicação. As funções presentes nos arquivos \verb|client_comm.cpp| e \verb|client_serialize.cpp| têm por função possibilitar a ponte entre as estruturas em C e seus formatos serializados para transmissão através da rede.

Estabelecida a estrutura básica de comunicação em código, a implementação seguiu-se de acordo com o diagrama de estados estabelecido no protocolo, sendo que a interface com o usuário traz complicações adicionais referentes ao tratamento de erros e processamento/sanitização de entrada.

A cada requisição com o coordenador, feita a partir de ação do usuário, uma nova conexão é montada e utilizada apenas para a aquela comunicação em específico, sendo que a especificação do protocolo não comporta qualquer outro tipo de uso. 

Na comunicação com o servidor, foi necessário o uso da multiplexação de entrada nos sistemas Unix, através da função \verb|select|, que possibilita a multiplexação sem bloqueio e sem o uso de threads (que causariam complicações adicionais de sincronização). No caso, a função \verb|select| possibilita o acompanhamento de duas conexões (ou mais) sem perda de processamento e com clareza de código (pela não necessidade de linhas diferentes de execução). Mais precisamente, para possibilitar a interação com o usuário e com o servidor ao mesmo tempo sem que um bloqueie o outro, pode-se adotar uma estratégia de {\em polling} sem timeouts para resolver o problema de escutar dois file descriptors diferentes sem bloqueio e sem perda de ciclos de processamento.

Foi tomado algum cuidado com a sanitização das entradas do usuário, sendo que tentativas de entrada em sala não existente, nomes inválidos e outras entradas inválidas foram sanitizadas e são descartadas pelo aplicativo.

\subsection{Coordenador}
O código do coordenador define algns tipos novos, que são as entidades mais importantes do código. Elas são:
\begin{enumerate}
	\item[1.] FILE\_DESC: É o tipo dos file descriptors. Foi colocado para facilitar a leitura do código e é uma outra denominação de int.
	\item[2.] PORT: é um inteiro sem sinal de 2 bytes, conforme especificado. Assim como FILE\_DESC, tem a finalidade de facilitar a leitura do código.
	\item[3.] message: struct que encapsula o que é importante para uma mensagem. Tem o stream de bytes a ser transmitido e o tamanho em bytes da mensagem, nacessário para o comando write. Em caso da ampliação do software mais informação, como o tipo da mensagem, poderia ser colocados para facilitar a utilização.
	\item[4.] server: é a entidade que guarda o nome do server e a porta na qual ele recebe comunicações do coordenador. Os serividores são armazenados em uma mapa que relaciona a porta na qual o servidor se comunica com os clientes e o servidor.
\end{enumerate}

O código é dividido em estados, os mesmos definidos no diagrama de estados do protocolo, destes alguns tem comunicação  com um cliente e outros se comunicam com um servidor. No início o coordenador abre um Socket e faz um bind para ouvir clientes e aguarda o primeiro contato. Ao receber a mensagem de um cliente, o coordenador interpreta o tipo de mensagem e dá o devido tratamento. Caso a mensagem recebida seja uma solicitação da lista de salas o coordenador simplesmente percorre o mapa de servidores e responde.
Caso seja uma solicitação de criação de sala o procedimento é dividido em duas partes: na primeira recupera-se o nome da nova sala e prepara a mensagem de resposta; na segunda parte a sala é criada de fato determinando a porta de comunicação com o cliente, a porta de comunicação com o servidor, fazendo o fork do novo processo e fazendo o ping no servidor (tudo caso o número máximo de salas não tenha sido excedido). Caso seja excedido o número máximo de salas não ocorre a criação.
O último caso é quando a mensagem solicita a deleção de uma sala. Nessa caso o coordenador pergunta ao servidor que controla a sala se ela pode ser deletada, ou seja, se está vazia. Em caso afirmativo a sala é deletada, caso contrário não há deleção. Caso seja solicita a delação de uma sala inexistente nada ocorre.
Muitas das ações incorretas do usuário foram contornadas para dar robustez ao sistema, como deleção e entrada em salas que não existem, quando o cliente fornece uma porta na qual não há servidor. Situações não tratadas são mostradas na seção de possíveis melhorias.

\subsection{Servidor}
Quando o servidor é iniciado, ele recebe como parâmetros as portas que ele deve dar binding e usar para a conversa com o coordenador e com os clientes, possibilitando a existência de vários servidores rodando no mesmo computador. O servidor fica percorrendo os files descriptors, analisando quais soferam alterações, e então dependendo da mensagem e do file descriptor realiza as operações necessárias. Isso foi possível com o uso da função \verb|select|.

Os files descriptors associdados são o do coordenador, um para entrada de novos clientes e um para cada cliente que está na sala. Desse modo podemos tratar adequadamente cada caso de mensagem recebida. O servidor mantém a lista de clientes conectados, de modo que seja possível saber a quem repassar as mensagens e se a sala pode ser deletada.

A robustez do servidor é garantida pelo fato de que cada vez que ocorre falha no recebimento ou envio de pacotes a um cliente o servidor percebe e considera que o cliente saiu da sala, de modo que o servidor consegue se manter funcionando sem ter clientes inexistentes na sala. Ainda tem o caso que o servidor tenta mas não consegue mais se comunicar com o coordenador, caso qual em que ele se encerra enviando mensagem de erro, uma vez que sem o coordenador ele nunca mais conseguiria ter a confirmação que pode se fechar, ficando sempre aberto.  

Para ter um código mais organizado, ele foi dividido em dois arquivos, sendo um o programa principal e o outro a parte responsável por encapsular e desencapsular a mensagem no formato definido pelo protocolo, bem como ler e escrever nos files descriptors.

\section{Testes}

Devido à alta interdependência dos componentes do sistema, torna-se difícil testar cada um dos subsistemas individualmente. Sendo assim, todos os testes executados são testes em nível de sistema, invocando ao mesmo tempo todas os programas. Os testes foram divididos, porém, aproximadamente por 

\subsection{Teste 1: funções do coordenador (local)}
As funções de criação, listagem e remoção de salas (comunicação cliente-coordenador) foram testadas, segundo listagem a seguir. Para este teste, todas as aplicações foram executadas localmente.

\begin{Verbatim}[label={Listagem (cliente)},xleftmargin=-1.5cm,xrightmargin=-1.5cm]
flap:bin firer$ ./coordinator &
[1] 3442
flap:bin firer$ ./client flap
Lista de salas (0 salas):
Operacao [(1) Entrar, (2) Criar sala, (3) Remover sala, (4) Sair do programa, (5) Refresh lista]: 2
Nome: Futebol
Lista de salas (1 salas):
  [ 4002] Futebol
Operacao [(1) Entrar, (2) Criar sala, (3) Remover sala, (4) Sair do programa, (5) Refresh lista]: 2
Nome: Ufologia
Lista de salas (2 salas):
  [ 4002] Futebol
  [ 4003] Ufologia
Operacao [(1) Entrar, (2) Criar sala, (3) Remover sala, (4) Sair do programa, (5) Refresh lista]: 2
Nome: Computacao
Lista de salas (3 salas):
  [ 4002] Futebol
  [ 4003] Ufologia
  [ 4004] Computacao
Operacao [(1) Entrar, (2) Criar sala, (3) Remover sala, (4) Sair do programa, (5) Refresh lista]: 2
Nome: Encontros
Lista de salas (4 salas):
  [ 4002] Futebol
  [ 4003] Ufologia
  [ 4004] Computacao
  [ 4005] Encontros
Operacao [(1) Entrar, (2) Criar sala, (3) Remover sala, (4) Sair do programa, (5) Refresh lista]: 3
Porta: 4004
Lista de salas (3 salas):
  [ 4002] Futebol
  [ 4003] Ufologia
  [ 4005] Encontros
Operacao [(1) Entrar, (2) Criar sala, (3) Remover sala, (4) Sair do programa, (5) Refresh lista]: 3
Porta: 4003
Lista de salas (2 salas):
  [ 4002] Futebol
  [ 4005] Encontros
Operacao [(1) Entrar, (2) Criar sala, (3) Remover sala, (4) Sair do programa, (5) Refresh lista]: 4
\end{Verbatim}


\subsection{Teste 2: teste de sala (local)}
A função de entrada na sala foi testada, testando assim a devida comunicação com o servidor. Para este teste, todas as aplicações foram executadas localmente.

\begin{Verbatim}[label={Tela de chat (cliente)},xleftmargin=-1.5cm,xrightmargin=-1.5cm]
----------------------------------------------------------------------------------------------------
CesarKawakami : Qtc?
CesarKawakami : Alguem fala comigo?
CesarKawakami : Ola!!!
CesarKawakami : Ola de novo!
CesarKawakami : Ola, mundo!
\end{Verbatim}


\subsection{Teste 3: teste de comunicação entre computadores diferentes (remoto)}
Neste teste, as aplicações de cliente e coordenador/servidor foram executadas em computadores diferentes. Ademais, diversos clientes na mesma sala foram testados.


\begin{Verbatim}[label={Listagem (cliente)},xleftmargin=-1.5cm,xrightmargin=-1.5cm]
flap:bin firer$ ./client 192.168.0.110
Lista de salas (0 salas):
Operacao [(1) Entrar, (2) Criar sala, (3) Remover sala, (4) Sair do programa, (5) Refresh lista]: 2
Nome: Futebol
Lista de salas (1 salas):
  [ 4002] Futebol
Operacao [(1) Entrar, (2) Criar sala, (3) Remover sala, (4) Sair do programa, (5) Refresh lista]: 3
Porta: 4002
Lista de salas (0 salas):
Operacao [(1) Entrar, (2) Criar sala, (3) Remover sala, (4) Sair do programa, (5) Refresh lista]: 2
Nome: Musica
Lista de salas (1 salas):
  [ 4003] Musica
Operacao [(1) Entrar, (2) Criar sala, (3) Remover sala, (4) Sair do programa, (5) Refresh lista]: 1
Porta da sala: 4003
Nome de usuario (somente alfanum): Cesar
Saiu da sala. Motivo: Pedido do usuario.
Lista de salas (1 salas):
  [ 4003] Musica
Operacao [(1) Entrar, (2) Criar sala, (3) Remover sala, (4) Sair do programa, (5) Refresh lista]: 4
\end{Verbatim}


\begin{Verbatim}[label={Tela de chat (cliente)},xleftmargin=-1.5cm,xrightmargin=-1.5cm]
----------------------------------------------------------------------------------------------------
schumi : tc de onde?
schumi : a/s/l?
schumi : oi
Cesar : teste2
\end{Verbatim}


\subsection{Teste 4: queda de cliente}
Neste teste, estando dois clientes conectados a uma mesma sala, um dos clientes foi derrubado repentinamente (através da função \verb|kill| do linux). O resultado foi satisfatório, tendo em vista que o servidor e o cliente restante continuaram rodando em absoluta normalidade. No teste abaixo, após a mensagem ''oi!!!'' do usuário ''schumi'', o cliente correspondente a este último foi terminado usando \verb|kill|. Observe a continuação da normalidade, resultado do bom tratamento de erros presente na implementação.

\begin{Verbatim}[label={Tela de chat (cliente)},xleftmargin=-1.5cm,xrightmargin=-1.5cm]
----------------------------------------------------------------------------------------------------
Cesar : tchau!
schumi : oi!!!
Cesar : oi
Cesar : oi
Cesar : oi
\end{Verbatim}

\subsection{Teste 5: queda do servidor}
Neste teste, estando um cliente conectado ao servidor, o servidor foi terminado repentinamente (através da função \verb|kill| do linux). O resultado foi satisfatório, sendo que o cliente detectou a queda do servidor (como falha de conexão) e retornou à tela principal, como mostrado na listagem abaixo. O texto ''***** Aqui ocorre chat e servidor foi derrubado *****'' foi inserido para melhor compreensão.

\begin{Verbatim}[label={Listagem (cliente)},xleftmargin=-1.5cm,xrightmargin=-1.5cm]
flap:bin firer$ ./client localhost
Lista de salas (1 salas):
  [ 4002] Sala
Operacao [(1) Entrar, (2) Criar sala, (3) Remover sala, (4) Sair do programa, (5) Refresh lista]: 1
Porta da sala: 4002
Nome de usuario (somente alfanum): Cesar
***** Aqui ocorre chat e servidor foi derrubado *****
Saiu da sala. Motivo: Falha na conexao com o servidor.
Lista de salas (1 salas):
  [ 4002] Sala
Operacao [(1) Entrar, (2) Criar sala, (3) Remover sala, (4) Sair do programa, (5) Refresh lista]: 4
\end{Verbatim}

\subsection{Teste 6: queda do coordenador}
Neste teste, estando um cliente executando, o coordenador foi terminado repentinamente (através da função \verb|kill| do linux). O resultado foi satisfatório, sendo que o cliente detectou a queda do coordenador (como falha de conexão) e terminou sua execução sem problemas. O texto ''***** Aqui foi derrubado coordenador *****'' foi inserido para melhor compreensão.

\begin{Verbatim}[label={Listagem (cliente)},xleftmargin=-1.5cm,xrightmargin=-1.5cm]
flap:bin firer$ ./client localhost
Lista de salas (1 salas):
  [ 4002] Sala
***** Aqui foi derrubado coordenador *****
Operacao [(1) Entrar, (2) Criar sala, (3) Remover sala, (4) Sair do programa, (5) Refresh lista]: 5
Erro ao conectar ao coordenador
flap:bin firer$ 
\end{Verbatim}

Note-se, porém, que o servidor disparado pelo coordenador, após a terminação do coordenador, continuará executando indefinidamente.

\section{Possíveis melhorias}

\subsection{Sistema}
O sistema não é robusto à falhas quando o coordenador, por algum motivo, deixa de existir. Neste caso, todos os servidores (salas) permanecem abertos indefinidamente. Uma solução para isso seria a existência de pings periódicos entre servidor e coordenador, permitindo que ambos atualizem suas existências mutuamente periodicamente.

\subsection{Cliente}
O sistema do cliente não checa em situações não-críticas a quebra de protocolo (falhando com graça neste caso). Sendo assim, situações como a queda de um servidor levam ao cliente ao fechamento do programa ao invés de possibilitar que este possa escolher outra sala para conversar.

Ademais, a intuitividade da interface do cliente poderia ser melhorada, sendo que interfaces guiadas a texto tendem a ter sua usabilidade prejudicada pelas possibilidades de interação. A sanitização da entrada não é absoluta, sendo que usuários muito mal-intencionados podem por ventura conseguir comportamento inadequado da aplicação; o ideal tratamento iria requerer uso mais intensivo de bibliotecas mais adequadas de interface gráfica/textural, como a \verb|ncurses| já utilizada no projeto.

\subsection{Coordenador}
O sistema do coordenador não checa quebras de protocolo, como fornecimento de tamanhos incompatíveis com as limitações, ou o fornecimento de um tamanho diferente do número de bytes transmitidos. Na versão atual do software caso o tamanho na descrição da mensagem se maior que o tamanho de fato transmitido o programa consegue identificar a situação e nada faz. O fato do coordenador não checar o cumprimento do protocolo baseia-se na hipótese de que a porção do cliente tratará erros vindos do cliente e se comunicará de acordo com o protocolo.

Outra possível falha é a queda de um servidor sem ser por ordem do coordenador. Nesse caso esse servidor permanecerá sendo mostrado como uma sala disponível e haverá problemas se um cliente tentar entrar nessa sala. Um possível solução é o ping esperádico entre coordenador e servidor, já citado como melhoria do sistema.

\subsection{Servidor}
Uma possível melhora seria uma checagem mais adequada de que se as mensagens recebidas estão seguindo o protocolo, uma vez que apenas há a checagem se o servidor consegue ler os pacotes sem erro. Outra possível melhoria é a existência de pings periódicos entre o servidor e o coordenador, conforme mencionado anteriormente. 

\section{Código}
O código, bem como os comentários, estão todos em inglês pois o código está disponibilizado como projeto open source para quem quiser contribuir. O endereço do repositório (que permite a visualização do código-fonte com colorização) é

\verb|http://code.google.com/p/sgnets/source/browse/#hg/code|

Adicionalmente, anexo a este relatório, segue arquivo ZIP com o código-fonte completo da aplicação, para Linux Ubuntu/Debian. A compilação pode ser feita diretamente através de um comando \verb|make| na raiz do diretório de códigos-fonte.

\subsection{Cliente}

Os arquivos correspondentes ao cliente são:

\begin{enumerate}
	\item \verb|client.cpp| --- Código principal de interação do cliente, lida com aspectos de interface textual (com \verb|ncurses|), sanitização de entrada e fluxo geral da aplicação.
	\item \verb|client_comm.h| e \verb|client_comm.cpp| --- Comunicação através de soquetes TCP e transição entre estruturas C e estruturas para encaminhamento pela internet.
	\item \verb|client_serialize.h| e \verb|client_serialize.cpp| --- Serialização e deserialização em termos de fluxos de bytes.
	\item \verb|messages.h| --- Estruturas C correspondentes à mensagens a serem trocadas especificadas no protocolo.
\end{enumerate}

\subsection{Coordenador}

\verb|coordinator.cpp| --- Contém todo o código da porção do coordenador.

\subsection{Servidor}

Os arquivos correspondentes ao servidor são:

\begin{enumerate}
	\item \verb|server.cpp| --- 
	Código principal do servidor, sendo responsável por iniciar as conexões com as outras partes do sistema e preparação da mensagem para envio através do \verb|server_serialize.cpp|.
	
	\item \verb|server_serialize.h| e \verb|server_serialize.cpp| --- 
	Parte responsável por preparar, enviar e ler na rede as mensagens, seguindo o protocolo especificado.

	\item \verb|messages.h| --- Estruturas C correspondentes à mensagens a serem trocadas especificadas no protocolo.

\end{enumerate}


\section{Conclusão}

O sistema funcionou como esperado, seguindo as especificações. Durante o desenvolvimento do sistema foi possível notar que o cuidado inicial em determinar o protocolo possibilitou o desenvolvimento de todos os sistemas paralelamente, sem que um sistema se preocupasse com a implementação dos demais.
Nas seções iniciais de testes quebras de protocolo geraram os principais erros, mostrando mais uma vez a importância deste item.

A robustez do software final foi aceitável, mas ainda é passível de melhorias. A preocupação em lidar com as falhas mais comuns em redes ou por mal uso do software revelaram novas facetas do problema complementando o aprendizado.

\end{document}
